\subsection{Comparação com atrasos}
\label{sec:disdelaycmp}

O efeito que a introdução de atraso provocou na comparação dos resultados entre as soluções $MSJDBC$ e $CJDBC$ é quase inexistente, pelo que se pode dizer que a introdução de atraso afecta as soluções na mesma proporção, levando à obtenção de resultados semelhantes à situação de ausência de atraso.

Em relação à solução $WJDBC$ notou-se uma perda desempenho enorme, resultado que já era esperado principalmente na operação de actualização (e inserção também). O $WJDBC$ bloqueia o acesso ao objecto do result set quando começa o processo de actualização de uma linha, e só o desbloqueia quando o processo termina. Com a introdução de atraso os threads mantêm o \gls{lock} durante mais tempo diminuindo a concorrência, e com o resultado prático de diminuir muito o desempenho.

Ao contrário do que se pensava inicialmente, afinal a soma das partes é maior do que o todo. Embora se introduza 8 vezes um atraso entre colunas, o atraso total verificado entre linhas usando o valor $8 \times atraso_C$ é bastante menor. A título de curiosidade o tempo total da realização do benchmark do atraso entre colunas foi de mais de 12h30 e o tempo total da realização do benchmark do atraso entre linhas foi de cerca de 6h30. O facto de a introdução de atraso entre colunas provocar mais atraso, também evidenciou mais diferenças entre os resultados na ausência de atrasos e os resultados com atraso.
